This section is intended to provide a background or context to various embodiments that are recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Location services based on the location of mobile devices are becoming increasingly widespread. Assistance data for assisted navigation systems, such as global navigation satellite systems (GNSS), have been specified and standardized for cellular systems, e.g., global positioning systems (GPS), European Galileo, and Russian Global Navigation Satellite System (GLONASS). An exemplary GNSS can comprise a network of satellites that broadcasts navigation signals including time and distance data. GNSS receivers pick up these broadcasted navigation signals and calculate a precise global location based thereon. Other examples of GNSS include, but are not limited to, satellite-based augmentation systems (SBAS), local area augmentation systems (LAAS), quasi-zenith satellite systems (QZSS), and hybrid receivers.
The delivery of such assistance data can be built on top of cellular system-specific control plane protocols including, e.g., the radio resource location services protocol (RRLP) for GSM networks, the radio resource control (RRC) protocol of layer 3 in wideband code division multiple access (WCDMA) networks, and IS-801 for Code Division Multiple Access (CDMA) networks, standardized in the 3rd Generation Partnership Project (3GPP) and 3GPP2 standards. In addition, the control plane protocols also support Radio Access Network (RAN)-specific positioning methods. Examples include Enhanced Observed Time Difference (EOTD) in RRLP and Idle Period DownLink—Observed Time Difference Of Arrival (IPDL-OTDOA). It should be noted that assistance data as described herein, can refer to GNSS assistance containing, but not limited to, navigation models, time assistance, reference location, atmosphere models, differential corrections, sensor assistance and acquisition assistance. The assistance data can also include e.g. position information, high-accuracy position information, multi-frequency multi-GNSS measurement data, computationally-generated measurements, sensor measurements, route information and waypoint information.
As described above, assistance data may include, amongst other data, navigation models for the satellites, reference location and reference time. Whether the reference location and time are accurate or not has a major impact on performance and thus, information regarding GNSS time is crucial in solving the GNSS receiver's position. Keeping accurate time in, e.g., an Assisted GNSS (AGNSS) terminal/receiver (where time information is provided as assistance data) requires, for example, either an accurate and expensive oscillator, power-consuming miniature atomic clock, frequent connection to the satellites, or frequent requests of the time assistance from the network. Frequent connections to, e.g., satellites and/or a network, are power-consuming and thus degrade the user experience.
In technical terms, accurate time assistance together with reference position allows for the prediction of a code phase and Doppler frequency search space for spread spectrum satellite broadcasts. Having a small search window improves sensitivity contributing to Time-To-First-Fix (TTFF) and availability. Both aspects are important from the customer-satisfaction point-of-view.
It should be noted that other assistance data, such as ephemerides, have a lifetime of several hours. Therefore, the need to update such information needs is relatively rare. However, with conventional oscillators, time can be kept sufficiently accurate in a terminal on the order of only tens of minutes. Hence, it would be beneficial to be able to maintain an accurate time relation in a terminal by some other system or method.
When a mobile terminal is operating in a network that is synchronized to GNSS time, it can use this information to maintain accurate time even when moving from one cell to another within the same network. However, in networks that may be either synchronous or asynchronous, such as Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN), the terminal does not know about the network's synchronization status and cannot utilize this potential. In certain synchronized networks, such as IS-95/2000 and WiMAX, synchronization is a feature that is defined in the standard. That is, time transfer is an intrinsic feature of, e.g., the IS-95/2000 system, where the 3GPP RRLP and 3GPP RRC define the time assistance for control using cell frame timings. In addition, IS-95 is directly synchronized to GPS time, so accurate GPS time is readily available from every cell, making the maintenance of accurate time in the handsets unnecessary. Hence the information is available to the terminal in the design phase. Moreover, these networks also broadcast the GPS time information.
Open Mobile Alliance secure user plane location (OMA SUPL) protocol does the same in the user plane, where a reference time is given in the form of a difference between the GNSS time and the cell frame timing of the serving base station. In IP-networks, clocks can be synchronized using protocols specifically designed for this purpose. Additionally, certain systems enable AGNSS receiver time assistance over IP/an IP network connection by utilizing different combinations of at least one of the following: a time transfer protocol; a time server; a GNSS-receiver for obtaining the relationships between the time-server's time and the GNSS time scales; a time server synched to a specified GNSS time; a service providing differences between GNSS time scales; and user plane assistance protocols for transferring the relationship(s) from a server to a terminal.